Method and apparatus for phased transition of legacy systems to a next generation backup infrastructure

ABSTRACT

One example method includes [searching a legacy data backup system and identifying, in the legacy data backup system, a legacy backup asset, identifying a type of the legacy backup asset, creating a wrapper service instance that corresponds to the type of the legacy backup asset, detaching the legacy backup asset from the legacy data backup system, receiving, by the legacy backup asset, backup calls and restore calls from a new data backup system that is different from the legacy data backup system, and servicing, by the legacy backup asset the backup calls and restore calls based on a state of the legacy backup asset.

FIELD OF THE INVENTION

Embodiments of the present invention generally relate to transitioningfrom legacy data protection systems to new data protection systems. Moreparticularly, at least some embodiments of the invention relate tosystems, hardware, software, computer-readable media, and methods for aphased approach to transitioning from a legacy data protection system toa next generation data protection system.

BACKGROUND

The emergence of next generation data protection platforms, such as theDellEMC PowerProtect for example, is the outcome of a modernizationjourney of backup and disaster recovery solution to meet theever-changing needs of physical, virtual and cloud environments.However, most enterprises today still rely on legacy backup solutions toperform critical to day-to-day operations and, for various reasons,transition of the assets between backup systems cannot be implementedwith a one-click, or rip-and-replace approach.

Data backup assets are critical systems for business data andapplications.

Any change in the implementation of the data protection strategy needsplanning, deployment considerations and, more importantly, the softwareupdate may not be viable immediately.

Depending on the size of the deployment, the transition from a legacysystem to a new system may span from a few months to years. Theownership model, underlying complexity, and the approval processes ofsome enterprises could contribute to this delay, along with othermodernization efforts like hardware refreshes, and re-platforming, forexample.

Large enterprises may prefer lower-risk approaches with lesserdisruption, and may have a low tolerance for missing their RecoveryPoint Objective (RPO). Hence, the transition in such scenario mayrequire the coexistence of legacy and next-generation backup systemsside-by-side until the transition is complete.

Further, support for all possible backup asset types may not beimmediately available with the modern infrastructures. Also, a certaintype of backup assets on a specific platform may not be supported due tolimited customer base, or they will be delivered incrementally by thenew system.

Finally, the disposal of the backup must adhere to the retention policyas per the organizational or regulatory needs. Building therecoverability path from the next-generation data protection platformfor the backups from multiple legacy systems is complex and timeconsuming.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which at least some of the advantagesand features of the invention may be obtained, a more particulardescription of embodiments of the invention will be rendered byreference to specific embodiments thereof which are illustrated in theappended drawings. Understanding that these drawings depict only typicalembodiments of the invention and are not therefore to be considered tobe limiting of its scope, embodiments of the invention will be describedand explained with additional specificity and detail through the use ofthe accompanying drawings.

FIG. 1 discloses aspects of a phased transition cycle.

FIG. 2 discloses ingestion of legacy backup assets to a new backupsystem.

FIG. 3 discloses some example asset transition phases.

FIG. 4 discloses components of an example abstraction layer.

FIG. 5 discloses an encapsulation of a legacy backup asset of a legacybackup system.

FIG. 6 discloses an example wrapper service implementation for a giventype of asset.

FIG. 7 discloses an example of a proof of concept with NetWorker and

FIG. 8 discloses an example wrapper service template and itsinstantiation.

FIG. 9 discloses an example configuration of multiple proxy services perlegacy backup asset.

FIG. 10 discloses an example assets under state#1, #2 and #3.

FIG. 11 discloses aspects of an example method according to someembodiments.

FIG. 12 discloses aspects of an example computing entity operable toperform any of the claimed methods, processes, and operations.

DETAILED DESCRIPTION OF SOME EXAMPLE EMBODIMENTS

Embodiments of the present invention generally relate to transitioningfrom legacy data protection systems to new data protection systems. Moreparticularly, at least some embodiments of the invention relate tosystems, hardware, software, computer-readable media, and methods for aphased approach to transitioning one or more assets from a legacy dataprotection system to a next generation data protection system.

Note that, as used herein, a ‘backup asset’ or ‘data backup asset’refers to an entity, which may comprise hardware and/or software, thatis an element of a backup system, and that may be configured to performpart, or all, of a data backup process and/or a data restore process. Abackup asset may be an element of a legacy backup system, and/or may bean element of a new backup system, examples of which may be referred toherein as being a ‘next generation backup system.’ A legacy backupsystem may be referred to with the shorthand notation ‘legacy system’and a new backup system may be referred to with the shorthand notation‘new system.’

In general, example embodiments of the invention may involve aniterative process in which one or more backup assets are checked, on aper-asset basis in some embodiments, to determine if they are ready tobe transitioned from a legacy system to a new system and, if so, thetransition may be implemented. If a backup asset is not ready to betransitioned, the iterative process may be repeated for that backupasset. This process may continue until all backup assets have beentransitioned.

The backup assets may go through multiple transition phases including,for example, a not-ready-for-transition phase, during which backup andrecovery processes will continue to be implemented using the legacybackup system. In a subsequent phase, a backup asset may be ready fortransition to the new system but may still need access to older backups.In this phase, data recovery may be implemented using the legacy system,while backups may be created using the new system. When the backup assetis ready to be moved, and access to older backups is no longer needed,the backup asset may be transitioned to the new system and allsubsequent backup and restore processes performed with the new system.

In order to transition a backup asset, an abstraction layer may beimplemented that serves as a bridge between the legacy system and thenew system. The abstraction layer, in combination with a backupasset-specific wrapper instance running a wrapper service for aparticular legacy backup asset, may continue to operate to protect thedata of one or more clients, but may do so under the governance of thenew backup infrastructure. Once the backup asset has transitioned to thenew system, the wrapper instance and wrapper service may be terminated.

Embodiments of the invention, such as the examples disclosed herein, maybe beneficial in a variety of respects. For example, and as will beapparent from the present disclosure, one or more embodiments of theinvention may provide one or more advantageous and unexpected effects,in any combination, some examples of which are set forth below. Itshould be noted that such effects are neither intended, nor should beconstrued, to limit the scope of the claimed invention in any way. Itshould further be noted that nothing herein should be construed asconstituting an essential or indispensable element of any invention orembodiment. Rather, various aspects of the disclosed embodiments may becombined in a variety of ways so as to define yet further embodiments.Such further embodiments are considered as being within the scope ofthis disclosure. As well, none of the embodiments embraced within thescope of this disclosure should be construed as resolving, or beinglimited to the resolution of, any particular problem(s). Nor should anysuch embodiments be construed to implement, or be limited toimplementation of, any particular technical effect(s) or solution(s).Finally, it is not required that any embodiment implement any of theadvantageous and unexpected effects disclosed herein.

In particular, one advantageous aspect of at least some embodiments ofthe invention is that backup assets may be transitioned in a phasedmanner, on a per-asset basis in some cases, from a legacy dataprotection system into a new data protection system. An embodiment mayenable transition of a backup asset to a new backup system withoutrequiring purpose built changes in the new backup system to support thetransition. An embodiment may, within a single data protectionenvironment, enable some backup assets to operated indefinitely on alegacy system, while enabling other backup assets to transition to a newbackup system.

A. Aspects of Some Example Operating Environments

The following is a discussion of aspects of example operatingenvironments for various embodiments of the invention. This discussionis not intended to limit the scope of the invention, or theapplicability of the embodiments, in any way.

In general, embodiments of the invention may be implemented inconnection with systems, software, and components, that individuallyand/or collectively implement, and/or cause the implementation of, dataprotection operations which may include, but are not limited to, datareplication operations, 10 replication operations, dataread/write/delete operations, data deduplication operations, data backupoperations, data restore operations, data cloning operations, dataarchiving operations, and disaster recovery operations. More generally,the scope of the invention embraces any operating environment in whichthe disclosed concepts may be useful.

At least some embodiments of the invention provide for theimplementation of the disclosed functionality in, or in connection with,existing backup platforms, examples of which include the Dell-EMCNetWorker and Avamar platforms and associated backup software, andstorage environments such as the Dell-EMC DataDomain storageenvironment. In general however, the scope of the invention is notlimited to any particular data backup platform or data storageenvironment.

New and/or modified data collected and/or generated in connection withsome embodiments, may be stored in a data protection environment thatmay take the form of a public or private cloud storage environment, anon-premises storage environment, and hybrid storage environments thatinclude public and private elements. Any of these example storageenvironments, may be partly, or completely, virtualized. The storageenvironment may comprise, or consist of, a datacenter which is operableto service read, write, delete, backup, restore, and/or cloning,operations initiated by one or more clients or other elements of theoperating environment. Where a backup comprises groups of data withdifferent respective characteristics, that data may be allocated, andstored, to different respective targets in the storage environment,where the targets each correspond to a data group having one or moreparticular characteristics.

Example cloud computing environments, which may or may not be public,include storage environments that may provide data protectionfunctionality for one or more clients. Another example of a cloudcomputing environment is one in which processing, data protection, andother, services may be performed on behalf of one or more clients. Someexample cloud computing environments in connection with whichembodiments of the invention may be employed include, but are notlimited to, Microsoft Azure, Amazon AWS, Dell EMC Cloud StorageServices, and Google Cloud. More generally however, the scope of theinvention is not limited to employment of any particular type orimplementation of cloud computing environment.

In addition to the cloud environment, the operating environment may alsoinclude one or more clients that are capable of collecting, modifying,and creating, data. As such, a particular client may employ, orotherwise be associated with, one or more instances of each of one ormore applications that perform such operations with respect to data.Such clients may comprise physical machines, or virtual machines (VM)

Particularly, devices in the operating environment may take the form ofsoftware, physical machines, or VMs, or any combination of these, thoughno particular device implementation or configuration is required for anyembodiment. Similarly, data protection system components such asdatabases, storage servers, storage volumes (LUNs), storage disks,replication services, backup servers, restore servers, backup clients,and restore clients, for example, may likewise take the form ofsoftware, physical machines or virtual machines (VM), though noparticular component implementation is required for any embodiment.Where VMs are employed, a hypervisor or other virtual machine monitor(VMM) may be employed to create and control the VMs. The term VMembraces, but is not limited to, any virtualization, emulation, or otherrepresentation, of one or more computing system elements, such ascomputing system hardware. A VM may be based on one or more computerarchitectures, and provides the functionality of a physical computer. AVM implementation may comprise, or at least involve the use of, hardwareand/or software. An image of a VM may take the form of a .VMX file andone or more .VMDK files (VM hard disks) for example.

As used herein, the term ‘data’ is intended to be broad in scope. Thus,that term embraces, by way of example and not limitation, data segmentssuch as may be produced by data stream segmentation processes, datachunks, data blocks, atomic data, emails, objects of any type, files ofany type including media files, word processing files, spreadsheetfiles, and database files, as well as contacts, directories,sub-directories, volumes, and any group of one or more of the foregoing.Example embodiments of the invention are applicable to any systemcapable of storing and handling various types of objects, in analog,digital, or other form. Although terms such as document, file, segment,block, or object may be used by way of example, the principles of thedisclosure are not limited to any particular form of representing andstoring data or other information. Rather, such principles are equallyapplicable to any object capable of representing information.

As used herein, the term ‘backup’ is intended to be broad in scope. Assuch, example backups in connection with which embodiments of theinvention may be employed include, but are not limited to, full backups,partial backups, clones, snapshots, and incremental or differentialbackups.

B. Overview

In general, and with reference to the example scheme 100 disclosed inFIG. 1 , example embodiments may implement an iterative approach, whichmay be performed on a per-asset basis, to transitioning of a backupasset from a legacy data protection system, also referred to hereinsimply as a ‘legacy system,’ to a new data protection system, alsoreferred to herein simply as a ‘new system.’ The iterative approach maybe implemented in relatively small, manageable, phases. An iteration ofsuch an approach may begin at 102 for a particular backup asset, andthen proceed to 104 where a decision is made as to whether the backupasset is ready to be transitioned and, if so, the backup asset may betransitioned 106 from the legacy system to the new system. The iterativeprocess may continue, for each backup asset, or a selected subset ofbackup assets, in a data protection environment, until the backup assetshave been transitioned from the legacy system to the new system.

In further detail, a phased transition approach according to someembodiments may involve fulfillment of various objectives to effectivelyand efficiently achieve backup asset transitions. One example of such anobjective is the implementation of a mechanism to retrofit a legacybackup asset until it is ready to be transitioned. In particular,customers typically do not want to juggle around the old and new backupsolutions and/or their installations to manage a data protection zone.Also, as a custodian of the product, the customer may need to create achannel for the migration of backup assets to phase out the legacybackup systems. Another such objective is the non-invasive integrationof backup assets until the backup assets can be refreshed. Particularly,not all customers will allow the new software or packages to be loadedon the backup assets right away.

With considerations such as these in mind, some example embodiments mayimplement a non-invasive approach to align the legacy backup assets intothe next-generation backup infrastructure in a phased manner, withoutthe need for rearchitecting the new system to enable the transition.This model may also help in continuing the support for applicationsenabled in legacy systems until the next-generation software addssupport for those applications. As such, example embodiments may enablethe seamless integration of backup assets from the legacy systems andmay allow the next-generation system to be built incrementally.

C. Aspects of Some Example Embodiments

C.1. Backup Asset Discovery and Vetting With reference now to FIG. 2 ,an initial part of a transition process may take the form of the exampleprocess 200 and, in general, may involve ingestion of one or more backupassets to a new data protection system, and a determination that a givenbackup asset is ready for the transition at a given time. Particularly,at 202 a discovery process may be performed in a protection environmentto identify data backup assets and their respective data protectionschemes, that is, the schemes that define particularly how the backupasset will operate to protect data. Next, for each backup asset, adetermination 204 may be made as to whether the backup asset should beingested, or transitioned, into the new DPS (data protection system).The outcome of the determination 204 may be ‘YES’ 206, or ‘NO’ 208 whichmay require a further assessment as to whether the backup assets shouldbe retired 210 and removed from service, or whether the transition ofthe backup asset should simply be delayed 212. It may be the case thatthe example process may be repeated multiple times, such as once foreach backup asset for example, to pick, or vet, some of the backupassets for transition (YES) and leave the rest to either decide later orfor decommission (NO).

C.2 Example Transition Phases of A Backup asset

In general, one or more backup assets managed by a legacy system maytransition through different phases until those backup assets are readyto be accommodated under, and operate with, the new data protectionplatform. With reference now to FIG. 3 , an example scheme 300 isdisclosed that indicates example transition phases for some backupassets.

In one phase 302, it may be determined that a backup asset is not readyto be transitioned from a legacy system to a new system. Backup assetsin this state (1) may continue to perform their backup, and recovery,operations performed in connection with the legacy data protectionsystem. In another phase 304, it may be determined that a backup assetis ready to be transitioned from a legacy system to a new system, butstill requires access to older backups, such as may have been createdwith the legacy system. Backup assets in this state (2) may performtheir recovery operations with the legacy data protection system, whilethe backup operations may be performed by backup assets in the new dataprotection system. In the phase 306, the backup assets may be ready tobe transitioned from the legacy system to the new system and,accordingly, may be moved to the new system. Backup assets in this state(3) may perform both their backup and recovery operations in the newsystem.

With continued reference to FIG. 3 , it may be useful for a particularbackup asset to continue operating with a legacy backup agent as thatbackup asset may not be able to take on a new software or packageupdate, such as may be required by the new backup system. As such,backup assets in these circumstances may remain at state (1). If thebackup assets are ready to be transitioned, or have moved past state(1), they can be transitioned but may need a mechanism to seamlesslyrecover the backup copies from the legacy systems due, for example, tolegal and compliance requirements. If no obligations of recovery ofbackup copies from legacy system exist for a backup asset, or the backupasset is past state (2), the backup asset may be moved to be under thepurview of the new backup system to operate like a native backup assetunder the new backup system. Until the backup assets are fully ready tonatively transition to the new system, they may still need to be atleast under the purview of the bridge or wrapper, that is, protection ofthose backup assets should be discoverable, monitorable, and theirprotection managed from the new system dashboard for all the backupassets within a logical protection zone or protection environment.

C.3 Abstraction Layer and Encapsulation

As disclosed in FIG. 4 , a level of abstraction, which may comprise theabstraction layer 400, may be employed in some embodiments to composethe backup assets from the legacy system into the new backupinfrastructure. In general, and as noted elsewhere herein, embodimentsof the invention may operate to transition backup assets from a legacysystem to a new system without the need to apply a software change inthe backup asset currently through the legacy system.

In general, the abstraction layer 400, which may act as a mediator, mayassume multiple roles. For example, the abstraction layer 400 mayinteract externally with the new backup system 402 for service contractimplementation, regarding the backup asset, depending on the type ofbackup asset that needs to be abstracted. The service contract mayspecify, for example, how the new backup system 402 will employ thebackup asset to protect data. Thus, the new backup system 402 mayoperate to discover backup assets in a protection environment, and thenapply one or more data protection policies to data protection operationsperformed by those backup assets, where the policies may be reflected orincluded in the service contract for the backup assets. The abstractionlayer 400 may also act internally as a bridge to one or more backupassets of the legacy backup system 404 and may have responsibility forthe operation of those backup assets in the legacy backup system 404.

As indicated in FIG. 4 , the abstraction layer 400 may operate inconnection with the new backup system 402 to discover backup assets, aswell as information about the legacy backup system 404. As well, theabstraction layer 400 may monitor performance of the legacy backupsystem. Information obtained as a result of the discovering andmonitoring processes performed by and/or at the direction of theabstraction layer 400 may be passed by the abstraction layer 400 back tothe new backup system 402. As well, the new backup system 402 may useinformation received from the abstraction layer 400 to pass instructionsto the abstraction layer 400 concerning the operation of backup assetsof the legacy backup system 404 and/or backup assets transitioning fromthe legacy backup system 404 to the new backup system 402. Both thelegacy backup system 404 and the new backup system 402 may compriserespective backup agents that cooperate with respective agents of one ormore backup assets to control the operation of the backup assets toprotect data.

With continued attention to FIG. 4 , and directing attention now to FIG.5 as well, details are provided concerning an example abstraction layer500 and encapsulation of a legacy data protection system. As indicatedthere, the abstraction layer 500 may act as a bridge that implementsincoming data protection calls from the backup asset(s) operating in thenew backup system 402 (FIG. 4 ), and may also report on the behavior ofthe legacy backup system 404 (FIG. 4 ) with respect to backup assets 502of the legacy backup system 404. With the model depicted in FIGS. 4 and5 , an existing backup agent of the legacy backup system 404 maycontinue to operate a backup asset under the purview of thebridge/wrapper 400/500, but under the governance of the new backupsystem 402.

C.4 Wrapper Service and Related Considerations

To facilitate interaction of a backup asset with the legacy backupsystem 404 and/or new backup system 402, each backup asset may eachinclude a respective instance of a wrapper service that may enable thebackup asset to operate, with the new backup system 402, the way thebackup asset was managed through the legacy backup system 404. Ingeneral, the wrapper service may, in effect, enable retrofitting oflegacy backup assets with the capability needed for the legacy backupasset to interact with the new backup system 402, while still preservingcertain capabilities of the legacy backup asset relating to the legacybackup system 404, such as the ability of the legacy backup asset toaccess old backups.

In some embodiments, the wrapper service instance may be bootstrappedwith the backup asset metadata, that is, may be populated and/orinstantiated with the backup asset metadata, from the legacy backupserver to enable the seamless transition of the backup asset to the newbackup system 402, as well as the recoverability of any older backupsthat were taken by the backup asset before the transition of the backupasset to the new backup system. The wrapper service may comprise an API(Application Program Interface) in some embodiments, and may also enablecommunications between the backup asset, legacy backup system 404, andnew backup system 402.

In terms of wrapper service maintenance and updates, the wrapper servicemay be relatively minimalistic in terms of code that needs to be writtenand maintained. Except for the part where the next-generation contractneeds to be bound to the legacy server components, there may be no coderewrite to talk to the legacy client. Example embodiments may reuselegacy components, as the shelf life of the wrapper service may beshort. For example, the wrapper service may only be needed until alegacy transitioning of a legacy backup asset to state (2) (see FIG. 3 )has been completed.

With reference next to FIG. 6 , further details are provided concerningan example wrapper service implementation for a given type of backupasset, where bindings are provided for a specific legacy backupsoftware. The example architecture 600 of FIG. 6 may include a newbackup system 602, or ‘next generation backup infrastructure,’ thatcomprises hardware and/or software. The operations of the new backupsystem 602 with respect to one or more backup assets 604 may be dictatedby a backup asset service contract 606. That is, the backup servicecontract 606 may comprise details concerning data protection operationsthat are to be performed by the backup assets 604 with respect to one ormore clients. As such, a client API contract may be provided as anelement or component of the backup asset service contract 606.

With respect to the client API contract, as long as that client APIcontract of the legacy system is maintained, the code written to bind aclient API contract of the next-generation asset with a legacy backupasset, such as the assets 604 for example, may not need to be updated ormodified, except to incorporate any bug fixes to the legacy backupserver components. If the contract changes, it may be most likely thatthe API contract is extended with non-breaking changes, or the changesare versioned to ensure backward compatibility and, hence, the backupasset 604 may not always need to be refreshed. Containerization for thewrapper service may make it easier and quicker to refresh the services,rather than defining the wrapper mechanism for upgrading the service. Anexample method for containerization of the wrapper service is disclosedelsewhere herein.

With particular attention now to the example of FIG. 6 , a single backupasset service contract 606 applies to multiple backup assets 604,however that is not necessarily required. In some cases, a backup assetservice contract may be specific to only a single backup asset. Thus,the arrangement in FIG. 6 is presented only by way of example. Thebackup assets 604 may each be of a particular type and/or operate toback up particular types of data. For example, one of the backup assets604 is type ‘FS’ (File System) which may operate to backup a filesystem, and the other backup asset 604 is type ‘Oracle,’ which mayoperate to backup an Oracle database. Finally, each of the backup assets604 may host one or more products, such as software for example,operable to perform backup operations. In the example of FIG. 6 , one ofthe backup assets 604 hosts legacy software Product A and Product B,both of which are Type ‘FS.’ As well, the other backup asset 604 hostslegacy software Product A and Product B, both of which are Type‘Oracle.’

Turning next to FIG. 7 , further details are provided concerning examplewrapper services. The example scheme 700 of FIG. 7 may comprise a dataprotection manager/service 702 that operates in connection with awrapper service instance 704 to control the operation of a legacy backupasset 706, one example of which is a NetWorker filesystem backup assetthat may operate to protect a filesystem. The wrapper instance 704 maybe instantiated at a particular legacy backup asset and, in someembodiments, a respective wrapper instance 704 is provided for eachlegacy backup asset that will be transitioned to a new backup system.

In more detail, the example data protection manager/service 702, whichmay be a new, or next generation, backup system, may function to manageone or more backup assets, and may also direct data backup and datarecovery operations performed by those backup assets. These operationsmay be performed in connection with the wrapper service instance 704which, in the example of FIG. 7 , encompasses the PPDM (DellEMC PowerProtect Data Manager) client API interfaces 704 a, which maycollectively define part or all of a ‘contract layer,’ variouscomponents 704 b which may provide for the discovery, interface with,and use of, backup assets, such as NetWorker backup assets in thisexample. The wrapper service instance 704 may also encompass variousother components, such as NetWorker specific selected components 704 c.The various elements of the wrapper service instance 704 may provide theability to bring legacy backup assets 706, such as a backup asset, or‘client,’ of a NetWorker backup system, into the purview of the dataprotection manager/service 702. That is, the wrapper service instance704 may act as a bridge between the data protection manager/service 702and the legacy backup asset 706 to facilitate the transition of thelegacy backup asset 706 into a new backup system such as the dataprotection manager/service 702. It is noted that PPDM is but one exampleof a data protection manager/service 702 that may be employed in someexample embodiments, but the scope of the invention is not limited toPPDM.

In some embodiments, a client API contract may published that enablesthe data protection manager/service 702 to interact with, and obtaininformation from, a backup asset. The client API contract may comprisevarious interfaces such as, but not limited to, discovery interfaces toinspect the client system, client platform, and client data protectionconfiguration. These interfaces may be used by the data protectionmanager/service 702 to pull information from one or more data protectionassets to the NetWorker server, and the interfaces may also be used toenable remote agent interaction with the data protection assets. Stillother interfaces that may be included in a client API contract includediscovery interfaces that may enable the data protection manager/service702 to fetch backup/index entries, such as by way of a query to amedia/index database. Finally, the wrapper service instance 704 mayenable a backup/recovery request originating from the data protectionmanager/service 702 to be fulfilled through a job executioninfrastructure that may already be present with in legacy backup systeminfrastructure.

C.5 Example Encapsulation Sequence

With reference next to FIG. 8 , details are provided concerning anarchitecture 800 and associated methods to encapsulate a legacy backupasset, such as a NetWorker client for example, so that the legacy backupasset may be brought within the purview of a new backup system such thatthe new backup system can control the operation of the legacy backupasset using the bridge/wrapper. As noted in the discussion of FIG. 3 , alegacy backup asset that cannot be readily transitioned to a new backupsystem may be placed in state (1). Once a legacy backup asset is readyto be transitioned to a new backup system, that is, State 3 in FIG. 3 ,the encapsulation of that legacy backup asset may be terminated. Theexample architecture 800 of FIG. 8 may include a new, or next .generation, data protection system 802, one example of which is theDellEMC PPDM system. The new data protection system 802 may interactwith an instance of a wrapper service 804 to provide services to one ormore legacy backup assets 806, examples of which include NetWorkerclients. Respective instances of the wrapper service 804 may be spawnedby a service handler 808.

In one example of a method 850 that may be performed in connection withthe architecture 800, an administrator of a new backup system, such asPPDM for example, may initiate 850 a backup and/or recovery of a legacybackup asset 806 that may not yet have transitioned from the legacybackup system to the new backup system. Before the initiation 850, theservice handler 808 must instantiate a wrapper service template to spawn852 the wrapper service instance 804 for the legacy backup asset 806concerning which the backup and/or recovery was initiated 850. Thewrapper service instance 804 may be a data protection system 802addressable endpoint by way of which the data protection system 802 mayaddress 854 the legacy backup asset 806.

The particular wrapper service instance 804 may depend upon the type ofthe legacy backup asset. Thus, the wrapper service template for thattype of legacy backup asset may have to be identified before the wrapperservice instance 804 can be spawned. In some embodiments, there may be aunique wrapper service template for a given legacy backup asset typesuch as “File system” or “Oracle,” for example, as

The wrapper service instance 804 may be registered with the legacybackup asset 806 address and its credentials. Next, the legacy backupasset 806 may be detached from its parent server, that is, its legacybackup server (not shown in FIG. 8 ), and the metadata corresponding tothe legacy backup asset 806 from its parent legacy backup server may bemigrated 856 to the wrapper service instance 804. Finally, the legacybackup asset 806 may be attached to the wrapper service instance 804 asits backup server. At this point, backup and restore operationsperformed by the legacy backup asset 806 may be controlled by the newdata protection system 802.

C.6 Example Deployment Model

In some example embodiments, a wrapper service may take the form of acontainer, such as the example containers 900 disclosed in FIG. 9 . Insome embodiments, a containers 901 may comprise a Docker container, butthat is not necessarily required. Similar to the case of a file wrapperinstance, a container 901 may communicate with a new data protectionsystem 902, which may be hosted on a data protection server, to enablethe control, by the new data protection system 902, of one or morelegacy backup assets 904. The new data protection system 902 may besimilar, or identical, to the new data protection system 702 discussedin connection with FIG. 7 .

In some embodiments, there may be a respective container image for eachwrapper service template. As noted elsewhere herein, a wrapper servicetemplate may be specific to a particular type of legacy backup asset903. In general, a respective specific image of the container 901 may berun for each legacy backup asset 903 to be ingested. A respectiveaddress associated with each of the containers 900 may be used toidentify and manage the legacy backup asset 904. This automaticallytakes care of the wrapper service refresh scenario and other containermanageability aspects. Note that some embodiments may avoid the storageof database files in a container 901 writable layer, but the use ofvolume of a container 901 may be considered when determining whether ornot the containers 900 may include database files.

Similar to the operation of the wrapper service instance 804, once acontainer 901 is up and running, the calls from the next-generationbackup server of the new data protection system 902 may be routed to acorresponding legacy backup asset 903, by way of a correspondingcontainer 901, as though the legacy backup asset were a native asset inthe new data protection system 902. The backup and restore serviceimplementation with the container 901 that is associated with a specificlegacy backup asset 903 may work with the legacy backup asset 903 toquery/spawn a job to backup/recover the data in a manner similar, oridentical, to the way in which that service was performed when directedby the legacy backup system.

As discussed above then, example embodiments may, among other things,create isolated instance of wrapper services, so that the specificlegacy backup asset can be encapsulated without patching the legacybackup asset to make it compatible with the new backup system, and thenthe legacy backup asset may be independently transitioned from thelegacy backup system to the new backup system without impacting the restof the legacy backup assets. This approach may also provide theflexibility of bringing the legacy backup assets from multiple instancesof the legacy backup service instance into the transition phase underthe purview of only a single instance of the next-generation backupinfrastructure. Finally, a container 901 may be removed from serviceonce the legacy backup asset 903 with which that container 901 isassociated has been transitioned from the legacy backup system to thenew backup system.

C.7 Example Legacy Backup Asset States

Directing attention next to FIG. 10 , a legacy backup asset may be inany of a number of different states 1000, as provided by exampleembodiments of the invention. In general, each state corresponds to aparticular stage of a transition process of a legacy backup asset from alegacy backup system to a new, or next generation, backup system.

When a legacy backup asset is in state #1 1002, both backup and recoverycalls from the new backup system may be routed from the wrapper serviceinstance, which may be running as a docker container, to the legacybackup asset. Even though the new backup system may control theoperation of the legacy backup asset in state #1, the backup andrecovery operations performed by the legacy backup asset may work thesame was as though those operations were being directed by the legacybackup system.

In state #2 1004, the wrapper service instance corresponding to a legacybackup asset may act as a passthrough for the backup related calls fromthe new backup system, which may be redirected to an interface of thelegacy backup asset so that the legacy backup asset operates as directedby the new backup system. Recovery operations may be performed by thelegacy backup asset as though those recovery operations were beingdirected by the legacy backup system. Thus, when the legacy backup assetis in state #2 1004, the legacy backup asset may perform backupoperations as it would if it were a native asset of the new backupsystem, that is, the legacy backup asset may perform backup operationsin the way that backup operations are performed in the new backupsystem, while the legacy backup asset may perform recovery operations inthe way that recovery operations are/were performed in the legacy backupsystem.

Finally, when the legacy backup asset has moved to state #3 1006, thetransition of the legacy backup asset from the legacy backup system tothe new backup system is complete. As such, the wrapper servicecontainer corresponding to that legacy backup asset may be dropped, thatis, deactivated, as the legacy backup asset may then be ready withsoftware required by the new backup system, and may have older backupcopies required to be recovered. From this point on, the legacy backupasset may be natively managed from the next-generation backupinfrastructure.

D. Further Discussion

Over last few decades, data protection platforms have been implementedin significant numbers. Even though such platforms may not necessarilyfulfill every evolving needs of modern machineries, the enterprisesusing those platforms may have already made large scale investments andmay be dependent on the partner ecosystems built around them forextension and customization. Hence, creating touch points for the phasedmigration of backup assets may be a key strategic element for businessesto retain and expand the data protection customer base in the enterpriseIT landscape. Correspondingly, example embodiments may implement varioususeful functionalities relating to the transitioning of backup assetsfrom a legacy backup system to a next-generation backup system. Forexample, some embodiments may be non-invasive in terms of updates thatare needed to be implemented on the backup assets, without requiring anypurpose-built changes in the next-generation backup infrastructure tosupport the transition of the backup assets.

As another example, some embodiments may enable a customer to initiatethe transition for some of their backup assets so as to experience thechanges that will be implemented by the next-generation backup solution,and the customer may then prepare the transition of the assets in aphased manner, which also keeps the risk of disruption lower. Finally,for backup assets that may need to remain in a legacy backup systemindefinitely, or possibly forever, due to customizations such aslock-ins to the legacy system, or due to lack of support for the backupassets in the next-generation backup software, such as dependency on thetapes or support for MediTech apps, administrators may employ exampleembodiments to continue the protection of such specific customerworkloads.

E. Example Methods

It is noted with respect to the example method of FIG. 11 that any ofthe disclosed processes, operations, methods, and/or any portion of anyof these, may be performed in response to, as a result of, and/or, basedupon, the performance of any preceding process(es), methods, and/or,operations. Correspondingly, performance of one or more processes, forexample, may be a predicate or trigger to subsequent performance of oneor more additional processes, operations, and/or methods. Thus, forexample, the various processes that may make up a method may be linkedtogether or otherwise associated with each other by way of relationssuch as the examples just noted. Finally, and while it is not required,the individual processes that make up the various example methodsdisclosed herein are, in some embodiments, performed in the specificsequence recited in those examples. In other embodiments, the individualprocesses that make up a disclosed method may be performed in a sequenceother than the specific sequence recited.

Directing attention now to FIG. 11 , an example method 1100 according tosome embodiments is disclosed. At 1102, a legacy backup asset type maybe identified, such as by an administrator or by a new backup system,where example asset types include a filesystem backup asset, or adatabase backup asset. With the asset type known, a wrapper serviceinstance may be created 1104 that is specific to the legacy backupasset. The wrapper service instance may be created 1104 by a servicehandler 1105 using a template.

The legacy backup asset to which the wrapper service instance appliesmay then be detached 1106 from its parent, that is, from the legacybackup system. Metadata relating to the legacy backup asset and thelegacy backup system may then be migrated 1108 to the wrapper serviceinstance. The metadata may enable the new backup system, and the wrapperservice instance, to interact with the legacy backup

After migration of the metadata 1108, the legacy backup asset is able toreceive 1110 backup calls and restore calls from the new backup system1112. The backup calls and restore calls may then be serviced 1114according to which state the legacy backup asset is in.

F. Further Example Embodiments

Following are some further example embodiments of the invention. Theseare presented only by way of example and are not intended to limit thescope of the invention in any way.

Embodiment 1. A method, comprising searching a legacy data backup systemand identifying, in the legacy data backup system, a legacy backupasset; identifying a type of the legacy backup asset; creating a wrapperservice instance that corresponds to the type of the legacy backupasset; detaching the legacy backup asset from the legacy data backupsystem; receiving, by the legacy backup asset, backup calls and restorecalls from a new data backup system that is different from the legacydata backup system; and servicing, by the legacy backup asset the backupcalls and restore calls based on a state of the legacy backup asset.

Embodiment 2. The method as recited in embodiment 1, wherein the servicewrapper instance is spawned by a service handler using a service wrappertemplate.

Embodiment 3. The method as recited in any of embodiments 1-2, furthercomprising migrating legacy backup asset metadata from the legacy databackup system to the new data backup system.

Embodiment 4. The method as recited in any of embodiments 1-3, whereinwhen the legacy backup asset is in a state (1), both the backup callsand the recovery calls are serviced by the legacy backup system andaccording to requirements imposed by the new backup system.

Embodiment 5. The method as recited in embodiment 4, wherein the legacybackup asset remains indefinitely in state (1) when the legacy backupasset lacks support in the new backup system.

Embodiment 6. The method as recited in any of embodiments 1-5, whereinwhen the legacy backup asset is in a state (2), the recovery calls areserviced using the legacy backup system, and the backup calls areserviced by the new backup system.

Embodiment 7. The method as recited in any of embodiments 1-6, whereinwhen the legacy backup asset is in a state (3), both the backup callsand the recovery calls are serviced by the new backup system.

Embodiment 8. The method as recited in any of embodiments 1-7, whereinthe wrapper service instance is implemented as a container.

Embodiment 9. The method as recited in any of embodiments 1-8, whereinthe wrapper service instance comprises an abstraction that facilitatescommunication between the new backup system and the legacy backupsystem.

Embodiment 10. The method as recited in any of embodiments 1-9, whereinan asset service contract of the wrapper service instance defines one ormore operations to be performed by the legacy backup asset, and theasset service contract is accessible by the new backup system.

Embodiment 11. A method for performing any of the operations, methods,or processes, or any portion of any of these, disclosed herein.

Embodiment 12. A non-transitory storage medium having stored thereininstructions that are executable by one or more hardware processors toperform operations comprising the operations of any one or more ofembodiments 1-11.

F. Example Computing Devices and Associated Media

The embodiments disclosed herein may include the use of a specialpurpose or general-purpose computer including various computer hardwareor software modules, as discussed in greater detail below. A computermay include a processor and computer storage media carrying instructionsthat, when executed by the processor and/or caused to be executed by theprocessor, perform any one or more of the methods disclosed herein, orany part(s) of any method disclosed.

As indicated above, embodiments within the scope of the presentinvention also include computer storage media, which are physical mediafor carrying or having computer-executable instructions or datastructures stored thereon. Such computer storage media may be anyavailable physical media that may be accessed by a general purpose orspecial purpose computer.

By way of example, and not limitation, such computer storage media maycomprise hardware storage such as solid state disk/device (SSD), RAM,ROM, EEPROM, CD-ROM, flash memory, phase-change memory (“PCM”), or otheroptical disk storage, magnetic disk storage or other magnetic storagedevices, or any other hardware storage devices which may be used tostore program code in the form of computer-executable instructions ordata structures, which may be accessed and executed by a general-purposeor special-purpose computer system to implement the disclosedfunctionality of the invention. Combinations of the above should also beincluded within the scope of computer storage media. Such media are alsoexamples of non-transitory storage media, and non-transitory storagemedia also embraces cloud-based storage systems and structures, althoughthe scope of the invention is not limited to these examples ofnon-transitory storage media.

Computer-executable instructions comprise, for example, instructions anddata which, when executed, cause a general purpose computer, specialpurpose computer, or special purpose processing device to perform acertain function or group of functions. As such, some embodiments of theinvention may be downloadable to one or more systems or devices, forexample, from a website, mesh topology, or other source. As well, thescope of the invention embraces any hardware system or device thatcomprises an instance of an application that comprises the disclosedexecutable instructions.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts disclosed herein are disclosed asexample forms of implementing the claims.

As used herein, the term ‘module’ or ‘component’ may refer to softwareobjects or routines that execute on the computing system. The differentcomponents, modules, engines, and services described herein may beimplemented as objects or processes that execute on the computingsystem, for example, as separate threads. While the system and methodsdescribed herein may be implemented in software, implementations inhardware or a combination of software and hardware are also possible andcontemplated. In the present disclosure, a ‘computing entity’ may be anycomputing system as previously defined herein, or any module orcombination of modules running on a computing system.

In at least some instances, a hardware processor is provided that isoperable to carry out executable instructions for performing a method orprocess, such as the methods and processes disclosed herein. Thehardware processor may or may not comprise an element of other hardware,such as the computing devices and systems disclosed herein.

In terms of computing environments, embodiments of the invention may beperformed in client-server environments, whether network or localenvironments, or in any other suitable environment. Suitable operatingenvironments for at least some embodiments of the invention includecloud computing environments where one or more of a client, server, orother machine may reside and operate in a cloud environment.

With reference briefly now to FIG. 12 , any one or more of the entitiesdisclosed, or implied, by FIGS. 1-11 and/or elsewhere herein, may takethe form of, or include, or be implemented on, or hosted by, a physicalcomputing device, one example of which is denoted at 1200. As well,where any of the aforementioned elements comprise or consist of avirtual machine (VM), that VM may constitute a virtualization of anycombination of the physical components disclosed in FIG. 12 .

In the example of FIG. 12 , the physical computing device 1200 includesa memory 1201 which may include one, some, or all, of random accessmemory (RAM), non-volatile memory (NVM) 1204 such as NVRAM for example,read-only memory (ROM), and persistent memory, one or more hardwareprocessors 1206, non-transitory storage media 1208, UI device 1210, anddata storage 1212. One or more of the memory components 1202 of thephysical computing device 1200 may take the form of solid state device(SSD) storage. As well, one or more applications 1214 may be providedthat comprise instructions executable by one or more hardware processors1206 to perform any of the operations, or portions thereof, disclosedherein.

Such executable instructions may take various forms including, forexample, instructions executable to perform any method or portionthereof disclosed herein, and/or executable by/at any of a storage site,whether on-premises at an enterprise, or a cloud computing site, client,datacenter, data protection site including a cloud storage site, orbackup server, to perform any of the functions disclosed herein. Aswell, such instructions may be executable to perform any of the otheroperations and methods, and any portions thereof, disclosed herein.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

1. A method, comprising: searching a legacy data backup system andidentifying, in the legacy data backup system, a legacy backup asset;identifying a type of the legacy backup asset; creating a wrapperservice instance, by the legacy data backup system, that corresponds tothe type of the legacy backup asset; detaching the legacy backup assetfrom the legacy data backup system; receiving, by the legacy backupasset through the wrapper service instance, backup calls and restorecalls from a new data backup system that is different from the legacydata backup system; and servicing, by the legacy backup asset the backupcalls and restore calls based on a state of the legacy backup asset. 2.The method as recited in claim 1, wherein the service wrapper instanceis spawned by a service handler using a service wrapper template.
 3. Themethod as recited in claim 1, further comprising migrating legacy backupasset metadata from the legacy data backup system to the new data backupsystem.
 4. The method as recited in claim 1, wherein when the legacybackup asset is in a state (1), both the backup calls and the recoverycalls are serviced by the legacy backup system and according torequirements imposed by the new backup system.
 5. The method as recitedin claim 4, wherein the legacy backup asset remains indefinitely instate (1) when the legacy backup asset lacks support in the new backupsystem.
 6. The method as recited in claim 1, wherein when the legacybackup asset is in a state (2), the recovery calls are serviced usingthe legacy backup system, and the backup calls are serviced by the newbackup system.
 7. The method as recited in claim 1, wherein when thelegacy backup asset is in a state (3), both the backup calls and therecovery calls are serviced by the new backup system.
 8. The method asrecited in claim 1, wherein the wrapper service instance is implementedas a container.
 9. The method as recited in claim 1, wherein the wrapperservice instance comprises an abstraction that facilitates communicationbetween the new backup system and the legacy backup system.
 10. Themethod as recited in claim 1, wherein an asset service contract of thewrapper service instance defines one or more operations to be performedby the legacy backup asset, and the asset service contract is accessibleby the new backup system.
 11. A non-transitory computer readable storagemedium having stored therein instructions that are executable by one ormore hardware processors to perform operations comprising: searching alegacy data backup system and identifying, in the legacy data backupsystem, a legacy backup asset; identifying a type of the legacy backupasset; creating a wrapper service instance, by the legacy data backupsystem, that corresponds to the type of the legacy backup asset;detaching the legacy backup asset from the legacy data backup system;receiving, by the legacy backup asset through the wrapper serviceinstance, backup calls and restore calls from a new data backup systemthat is different from the legacy data backup system; and servicing, bythe legacy backup asset the backup calls and restore calls based on astate of the legacy backup asset.
 12. The non-transitory computerreadable storage medium as recited in claim 11, wherein the servicewrapper instance is spawned by a service handler using a service wrappertemplate.
 13. The non-transitory computer readable storage medium asrecited in claim 11, further comprising migrating legacy backup assetmetadata from the legacy data backup system to the new data backupsystem.
 14. The non-transitory computer readable storage medium asrecited in claim 11, wherein when the legacy backup asset is in a state(1), both the backup calls and the recovery calls are serviced by thelegacy backup system and according to requirements imposed by the newbackup system.
 15. The non-transitory computer readable storage mediumas recited in claim 14, wherein the legacy backup asset remainsindefinitely in state (1) when the legacy backup asset lacks support inthe new backup system.
 16. The non-transitory computer readable storagemedium as recited in claim 11, wherein when the legacy backup asset isin a state (2), the recovery calls are serviced using the legacy backupsystem, and the backup calls are serviced by the new backup system. 17.The non-transitory computer readable storage medium as recited in claim11, wherein when the legacy backup asset is in a state (3), both thebackup calls and the recovery calls are serviced by the new backupsystem.
 18. The non-transitory computer readable storage medium asrecited in claim 11, wherein the wrapper service instance is implementedas a container.
 19. The non-transitory computer readable storage mediumas recited in claim 11, wherein the wrapper service instance comprisesan abstraction that facilitates communication between the new backupsystem and the legacy backup system.
 20. The non-transitory computerreadable storage medium as recited in claim 11, wherein an asset servicecontract of the wrapper service instance defines one or more operationsto be performed by the legacy backup asset, and the asset servicecontract is accessible by the new backup system.